Conventionally, confirmation of documents or financial transactions by authorized individuals have been guaranteed by signature in the presence of a notary or, e.g., a vendor at a point of sale transaction. Further, some transactions are explicitly authorized and confirmed provided that a prior authentication process has been satisfied. Such authentication processes include, for example, password authentication (ATM, Debit card, phone banking) or checking an individual's signature against the signature on a credit card in the possession of the individual after authorization (or at least in case of dispute of a credit card payment).
In the case of remote electronic transactions over the telephone or the Internet, an individual can provide credit card information to a secure server using, e.g., DTMF (Dual Tone Multi-Frequency) communication, voice dialogs with either a machine, e.g., IVR (Interactive Voice Response) or human operators, and/or GUI (graphical user interface) form filling (password/PIN, login). With such remote transactions, however, the individual's signature is not provided, which may place some or all of the financial risk of a fraudulent transaction on the merchant or credit card provider when the authorized user disputes and successfully reverses the charges.
The expansion of online and other electronic transactions has amplified the requirements for more efficient payment authentication procedures. To provide security for remote transactions, various protocols have been utilized using digital certificates to provide digital authentication and signature mechanisms. These protocols can be combined with encryption schemes (e.g., public key and private key) and watermarking.
For example, SET is a protocol that was developed to ensure the security of remote financial transactions over the Internet, for example. Using SET, a financial transaction can be conducted and verified between a consumer, and vendor, and the consumer's service provider or banking institution using both digital certificate and digital signature technology.
More particularly, according to the SET protocol, the banking institution or third-party service provider of the consumer will issue digital certificates to the consumer and the vendor. The digital certificates, in general, may contain information such as the name of the person to whom it was issued, a serial number, an expiration date, a public key, and/or the digital signature of the issuing authority (e.g., the consumer's banking institution/service provider). For processing a remote financial transaction, the client device of the consumer must be running a local program that is capable of encrypting and processing all the information exchanged with the vendor. The vendor must first provide all the transaction information and then provide the digital certificate to the consumer so that the consumer can verify/authenticate the vendor. The vendor authentication process may also be performed by the consumer's bank or service provider.
Upon vendor authentication, the consumer will transmit a purchase order to the vendor (which is encrypted with the vendor's public key), as well as an encrypted credit card authorization (which the vendor can not decode). The vendor then forwards this information to the consumer's service provider or banking institution for verification. Upon acceptance from the bank, the vendor receives an authorization notification. The transaction is then performed and an e-receipt is sent to the consumer.
U.S. Pat. No. 6,016,476, entitled “PORTABLE INFORMATION AND TRANSACTION PROCESSING SYSTEM AND METHOD UTILIZING BIOMETRIC AUTHORIZATION AND DIGITAL CERTIFICATE SECURITY”, describes another protocol for performing a secure transaction. According to this protocol, periodic server-side authentications are performed on a server, which result into the download of expiring digital certificates to a client device (or software on a PC (personal computer) or other device), the walletpad, that can now contain the credit card information. Upon local authentication (biometric) and valid digital certificate, the credit card information is freed to perform a local (conventional credit card) or online transaction.
As illustrated above, conventional authentication protocols require complex digital certificate processing capabilities that have not yet been widely adopted. Indeed, to use the SET protocol, for example, the vendor must have the infrastructure to process the handshake with the e-wallet (digital certificate) of the consumer, to track the consumer's order, to determine the consumer's banking institution or service provider, and to forward the information to the bank or service provider and wait for the confirmation.
It would be advantageous to have a protocol that provides secure financial transactions without requiring a complex digital exchange as required by conventional protocols such as SET. Accordingly, a protocol that is capable of providing security for remote transaction, but which is compatible with the existing infrastructure, is highly desirable.